The present invention relates to resource lists and, more specifically, to sharing subscriptions to resource list content in a resource list server.
The Session Initiation Protocol (SIP) event notification mechanism allows a user to subscribe to the presence state of a list of resources. Lists are identified by a Uniform Resource Indicator (URI), and may be personal, such as the buddy list of a user, or public, intended to be shared by multiple users.
In the SIP architecture, a presence subscription to a resource list is handled by a Resource List Server (RLS) that aggregates the state of the list members and notifies the subscriber of the state of every resource in the list. The RLS also notifies the subscriber whenever the state of a list member changes.
In a typical SIP architecture, the lists are stored separately from the RLS, in an extensible markup language (XML) repository. The XML Configuration Access Protocol (XCAP) is used to create, modify and retrieve lists from the repository. XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.
In order to serve a SUBSCRIBE request to a resource list, the RLS first needs to retrieve the content of the resource list from the XCAP server, aggregate the presence state of all list members, and send the aggregated presence information to the subscriber. It is not enough for the RLS to retrieve the current content of the group once, because if a resource is later added or removed from the list, RLS needs to notify the subscriber. Thus, if a resource is added to the list, the RLS needs to send a notification to the presence subscriber, where the notification contains the presence state of the new list member. Similarly, if a resource is removed from the list, the RLS notifies the subscriber that the resource was removed from the list. In order to find out about changes to the content of the list, the RLS needs to subscribe to the content of the list by sending a SIP SUBSCRIBE message to the XCAP server. With this outgoing subscription, if a resource is added or removed from the list, the XCAP server sends a notification about the list change to RLS, and RLS can then notify its incoming subscriber.
With public resource lists, there may be multiple incoming presence subscriptions for the same list. As a result, the RLS creates multiple outgoing list content subscriptions with the XCAP server for the same list (one outgoing list content subscription per each incoming presence subscription). In some case there may exist tens or even hundreds of subscriptions for popular lists. This creates significant overhead on both the RLS and the XCAP Server. In particular, subscriptions represent ongoing sessions and require the server to store the session's state in memory (SIP headers, etc.), which consumes significant amounts of memory. In addition, separate notifications of the list content are sent for each subscription, resulting in a large number of notifications that carry the same information. This creates overhead on the XCAP Server, which needs to generate and send the notifications, and the RLS, which has to process these notifications. Of course, the multiple notifications also generally increases network load.
One solution is for RLS to create only one outgoing subscription to the XCAP server and share the information between all incoming presence subscriptions to the same list. The problem with this solution is that the content of the list is sensitive information and access to the list is subject to access policy defined by the owners of the list and enforced by the XCAP server. If the RLS uses the identity of one of the users in the outgoing subscription to the XCAP server, and then uses this information to send notifications of the state of the list to another subscriber, it actually exposes the content of the list to the second subscriber without verifying that the second subscriber has read access to the content of the list.